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. J. 


TECHNICAL MEMORANDUM 

INTRODUCTION TO THE SPACE PHYSICS ANALYSIS NETWORK 
(SPAN) - FIRST EDITION 


I. HISTORY OF THE SPAN AND DSUWG 

A considerable evolution has occurred in the past two decades in the disci- 
plines of Solar-Terrestrial and Interplanetary Physics. Early research v.'as 
centered around exploratory missions in which measurements from individual 
scientific Instruments could be meaningfully employed to advance the state of 
knowledge. As these scientific disciplines have progressed, a much more pro- 
found and interrelated set of questions is being posed by researchers. The 
result is that present-day investigations are generally much more complex: 
large volumes of data are acquired from multiple sensors on individual space- 
craft or ground-based systems, and quite often, data are needed from multiple 
sources in order to address particular physical problems. 

It is clear that research in solar-terrestrial physics during the 1980s and 
beyond will be devoted to intense multi-disciplinary studies aimed at ex- 
ploring very complex physical questions. It is recognized that major future 
advances in solar and space physics will require close collaboration among 
investigators through interactive exchange of scientific information. The 
problems of data exchange are exacerbated by the lack of standards for scien- 
tific data bases. The net result is that, at present, most researchers 
recognize the value of multi-disciplinary studies, but the cost in time and 
effort is devastating to their research efforts. This trend is antithetical 
to the needs of the NASA research community. 

In May 1980 the Space Plasma Physics Branch of the Office of Space Science of 
NASA Headquarters funded a pilot project at Marshall Space Flight Center 
(MSFC) to investigate ways of performing correlative space plasma research on 
a daily basis on a nationwide level. As a first step, a user group was 
formed called the Data Systems Users Working Group (DSUWG) to provide space 
science community interaction and direction in the project. After the first 
meeting of the DSUWG in September 1980, it was decided that the approach 
would be to design, build, and operate a network that would be a data system 
testbed which would be specifically mission independent. In addition, the 
construction of the system would be designed to use existing hardware as much 
as possible and take full advantage of "off the shelf" software and hard- 
ware. 

The Space Physics Analysis Network (SPAN) first became operational in 
December 1981 with three major nodes: University of Texas at Dallas, Utah 

State University, and MSFC (under the name MSFC/NEEDS Network and later under 
the name Space-plasma Computer Analysis Network or SCAN). Since that time it 
has grown rapidly (see Section II). SPAN has developed largely within the 
space plasma physics community through grass-roots efforts to facilitate 
space data analysis by providing electronic mail, document browsing, access 
to distributed data bases, facilities for numeric and graphic data transfer. 




access to Class VI machines, and entry to gateways for other networks. At 
present, SPAN is built on a VAX-based central node which was implemented as a 
technology testbed for high rate data capture and archiving (see for example, 
Thomas [1]), The emphasis of the SPAN is determined by the DSUWG. SPAN 
presently uses existing Digital Equipment Corporation computers as network 
nodes (usually already paid for by NASA for a wide variety of missions) and 
communicates over leased lines using the DECnet protocol. 

SPAN provides a common working environment for sharing of computer resources, 
sharing of computer peripherals, solving proprietary problems, and providing 
the potential for significant time and cost savings for correlative data 
analysis (see Green et al . [2] and Green [3]). The DSUWG continues to pro- 
vide guidance for SPAN growth and seeks to use standardization for the effi- 
cient exchange of data and graphics. The DSUWG is drawn from its present and 
potential user community as well as other interested, active scientists and 
data system managers. It has been continuously active since 1980 providing 
guidance to the Solar Terrestrial Division (now the Space Plasma Physics 
Branch of the Earth Science and Applications Division) in NASA's Office of 
Space Science and Applications (see Greenstadt and Green [4], Baker et al . 

[5], Green et al . [6] and Green et al . [7]). 

The DSUWG is structured along lines conducive to addressing major outstanding 
problems of scientific data exchange and correlation. There is a chairman 
for each subgroup to coordinate and focus the group's activities and the 
Project Scientist (J. L. Green) to oversee the implementation of the DSUWG 
recommendations and policies. The working group itself is divided into sev- 
eral subgroups which address issues of policy, networking and hardware, soft- 
ware and graphics standards, and data base standards. Appendix A is a de- 
tailed list of the DSUWG membership organized by subgroups. 

The DSUWG is a dynamic, evolving organization. We expect members to move in 
(or out) as appropriate to their active involvement in data related issues. 

We also realize that at present SPAN and the DSUWG are dealing with only a 
limited portion of the whole spectrum of problems facing the NASA community. 

As present problems are solved, as the network evolves, and as new issues 
arise, we look to the DSUWG to reflect these changes in its makeup, its struc- 
ture, and focus. 


2 




II. PRESENT CONFIGURATION OF THE NETWORK 


SPAN links together computers in the United States {and Europe in the near 
future) which are used for space physics data analysis. The SPAN currently 
reaches across the continental United States, coast to coast and border to 
border (see Fig. 1). At this time (March 1985), there are 20 computers that 
are a part of the SPAN. This includes machines as small as a PDP-11/23+ and 
as large as a dual processor VAX 11/782 and a VAX Cluster. Nearly all of the 
machines are linked together using the commercially available software pack- 
age DECnet. DECnet allows suitably configured Digital Equipment Corporation 
(DEC) computers (PRO'S, PDP's, VAX^s, and DECSYSTEM' s) to communicate across 
a variety of media (fiber optics, coax, leased telephone lines, etc.) utiliz- 
ing a variety of low level protocols (DDCMP, Ethernet, X.25). There are also 
several institutions that are currently connected to the central computer as 
simple computer terminals. 

The topology of SPAN is best described as a modified star (Fig. 2). The 
NEEDS VAX located at MSFC is at the center of the star with most other net- 
work machines connected to it over leased telephone circuits that radiate 
from the NEEDS VAX. Several institutions have local area networks that allow 
a number of different machines to be connected to SPAN. Regardless cf a 
machine's position in the network (either physical position in the US or 
logical position within the network), each machine sees all the other 
machines as "equals." A SPAN node that is located across the country and is 
reachable by linking through five intermediate nodes is as transparently 
accessible as a SPAN node sharing the same machine room with the originating 
system. 

SPAN is currently using a number of different physical communications techno- 
logies. The media used most often for wide area links is ATT Communications 
(ATTCOM) Digital Data Service (DOS) at 9.6 kb/s. Several wide area links use 
ATTCOM's older analog Dataphone II service at 4.8 and 9.6 kb/s. Local links 
typically use some sort of high speed communications. Examples are the 56 
kb/s fiber optics link between NEEDS and SSL, the 19.2 kb/s Local Area Data 
Service link between NEEDS and MIPS1, the 1 Mb/s DMR-DMR link between PACF 
and NSSDC, and the 10 Mb/s Ethernet links used at STARLAB. While the commun- 
ications technologies differ, the software protocol, DECnet, remains the same 
at the user level . 

There are several capabilities and features that SPAN is developing, making 
it unique within the space science community. The SPAN system provides 
remote users with access to space science data bases and brings scientists 
throughout the country together in a common working environment. Unlike all 
past and present space science networks, where the remote sites have only 
remote terminals (supporting one person at the remote site at a time), SPAN 
supports many users simultaneously at each remote node through computer to 
remote computer communication software. Users at their Institutions can par- 
ticipate in a number of network functions Involving other remote computer 
facilities. Data and graphics files can be transferred between network 
nodes. Program execution can be initiated from any of the network nodes 
(distributed processing). All of the nodes (excluding end nodes) have the 
capability for message routing, enabling the remote nodes to communicate with 
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each other as If a direct phone line existed between them, even though there 
may not be 'adjacent' nodes within the network. 

Little scientific application software has been traded in the space science 
community, particularly because of its labor-intensive nature. In a network 
environment, such as SPAN, software trading is extremely easy and has been 
done extensively. The network also supports the transmission and reception 
of manuscripts. This significantly reduces the time it takes to perform 
correlative work when authors are located across the country. 

Current funding for SPAN comes from two sources at NASA Headquarters: Code 

El (funding the basic research and development of the system) and Code T 
(funding all SPAN communications). Code T and MSFC are instituting a new 
NASA communication highway called the PSCN (Program Support Communications 
Network). Much like the GSFC NASCOM system for realtime data flow, SPAN will 
use the PSCN for all future communication requirements starting in, late 1985. 
It has been projected that the present SPAN system will be providing science 
support using the NASA PSCN at least into the 1990' s. PSCN will provide 
considerable enhancement and flexibility in the types of communications need- 
ed for SPAN in the upcoming years. A modest growth for SPAN of 100% has also 
been projected over this time period. 

SPAN will continue to be used as a testbed between space science investiga- 
tors with the intent of exploring and employing modern computer and communi- 
cation technology as a tool for doing space science research. This can be 
accomplished since SPAN is not a project-dependent system that requires a 
static hardware and software configuration for the duration of a mission. 

With the addition of new nodes come more and diverse data bases, more NASA 
facilities, more distributed computing power, and more scientific expertise. 
Within the next few years, new developments in software and hardware will be 
implemented on SPAN that will greatly aid space science research. What would 
have taken weeks or months to accomplish will be done in minutes. It is 
anticipated that SPAN will greatly improve its access to gateways into Europe 
and other locations throughout the world. SPAN might well soon become 
another of the essential tools needed for conducting effective space science 
research . 


Ill, NODE MEMBERSHIP 


Membership in the SPAN network is open to all interested space science groups 
who have sufficient computer resources to allow a link to be established. 

The following guidelines outline the procedures to follow to apply for node 
membership and what is expected of each node. 


A. SPAN Node Application 


Written proposals should be sent to Dr. James L. Green, NASA/ MSFC, Code ES53, 
Huntsville, Alabama, 35812. (Special note: limited funding is available for 

hardware and software requests.) The proposal should address the following 
questions: 


1. Why do you wish to become a node on the network: what are your 
goals. For example, this could Include scientific research, networking or 
communications testing, and the standardization of space science data and 
graphics. 


2. What facilities and capabilities do you wish to link into the 
network and describe how this will be accomplished. 

3. Are there any facilities at your node that would be available to 
remote users. If so, outline what procedures you require for remote users to 
gain access to your facilities. 

4. What are your projected timelines for accomplishment of network 
connections. 

5. Do you foresee a long-term involvement in SPAN. 


Proposals will be reviewed by the DSUWG steering committee with a formal pre 
sentation made to the full DSUWG. Once on SPAN it is expected that a repre- 
sentative from your node will participate in the activities of the DSUWG. 


B. MINIMUM HARDWARE ENTRANCE REQUIREMENTS 


SPAN not only provides communication for cooperative space science activi- 
ties, SPAN is also a testbed for network communications. Innovative network 
communications that are proposed to be used over SPAN are encouraged. 
Currently, the organizations who wish to become fully functional nodes 
quickly will need a system composed of Digital Equipment Corporation (DEC) 
hardware and software. Fully functional nodes currently include any DEC 
processor and operating system capable of supporting an appropriate version 
of the DECnet software package along with a correctly configured communica- 
tions port. The networking protocol used on such systems is DECnet. 

SPAN is currently working with organizations who wish to become network nodes 
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but do not have equipment capable of supporting OECnet. These sites include 
non-DEC computer systems as well as DEC computers executing the UNIX opera- 
ting system. Partially functional nodes have been proposed for these sites 
and experimental network testing has begun. 


C. MINIMUM NODE MANAGEMENT REQUIREMENTS 


In order to ensure that the network functions smoothly, it is necessary that 
SPAN nodes conform to a small number of node management requirements. These 
requirements fall into two broad categories: network functionality and 

network security. 


1. Functionality 

a. Every node must designate a system manager that Is capable of and 
directed to respond to the network manager's requests for information, apply- 
ing updates to the DECnet data base and being responsible for node security. 

b. Every node must provide Information on Its network users. Every 

node should have in its DECnet default account a file named USERLIST.LIS that 
contains the following Information on every SPAN user as a minimum: the 

user's name ("Joe Smith"), his account ("SMITH"), and his default account 
”S7S$SYSDEVICE:[SMITH] (UIC and "Charge Account" information are desired 
but are not required.) This user list should be updated to reflect the 
current user population every month. This information is used by network 
users to locate and contact other users on the network. 

c. Every node should provide information on its facilities. A file 

named NODEINFO. LIS should exist in the node's DECnet default account which 
includes the following information: The name, phone number, postal service 

mail address, and package delivery address of the system manager; the phys- 
ical location of the computer/ terminal and the modem; a phone number for the 
computer/terminal room; and a short description of the node's hardware, 
software, and special facilities. This information is needed to allow other 
system managers to know what areas of expertise exist at various nodes and to 
Inform network users of available facilities. Use of local resources are at 
the discretion of local management. 

d. Every node should keep their DECnet data base up to current SPAN 
revision levels. This is to keep the entire network functioning correctly. 

e. Every node should keep its relevant operating system and net- 
working software up to the manufacturer's current revision level (VAX/VMS, 
RSX-11M, IAS, DECnet, etc.). 
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2. Security 


a. Every node should lock its DECnet default account to keep It from 
being logged onto Interactively (VAX/VMS). If It cannot be locked from Inter- 
active use, the password should be given only to other SPAN system managers 
for inclusion In their DECnet data bases (RSX, IAS). 

b. The node system manager should make a conscientious effort to 
eliminate trivial passwords mi local user accounts. As many as possible of 
the security guidelines HsU^J in Chapter IV, Section B should be used. 


D. ACKNOWLEDGEMENTS 


All scientific and technical manuscripts whose preparation is aided by use of 
the network and the facilities on the network should include an appropriate 
acknowledgement. The following Is an example of a typical acknowledgement 
from a recent scientific paper. 

“The authors would like to express their gratitude to the Data System Tech- 
nology Program (DSTP) and the Space Physics Analysis Network (SPAN) pilot 
project for use of computing and networking facilities." 

The continued funding of special network facilities and SPAN communications 
depends largely on justifying the use of the system. Thus, it is essential 
that the SPAN be acknowledged when appropriate. A simple rule for SPAN users 
to follow is that if SPAN is used and acknowledged the node will remain con- 
nected to the network. For the healthy continuation of SPAN, its usefulness 
must be continuously documented. 

Please send a notification of acknowledgement for SPAN usage to SSL::GREEN. 

It is not necessary to send a paper or manuscript. Notification of acknowl- 
edgement for use of remote node facilities should be arranged between the 
parties involved. 


IV. SECURITY AND CONDUCT ON THE NETWORK 


A. Rules of the Road 


SPAN users must realize that others are on the network. They should retain 
the same standards of courtesy that they use In dealing with others at their 
home Institution. Just as it Is considered to be unacceptable for a person 
to walk into an office or laboratory and pry Into file cabinets, so It Is 
unacceptable for someone to pry through another network user's disk files. 
Also, anytime a researcher allows another person to use his data, analysis 
software, special facilities, etc., the user should Include an acknowledge- 
ment in any resulting papers, thanking the original researcher. Any papers 
published where the author uses SPAN for gathering data, sharing data, elec- 
tronic mall, conference calls, etc. should Include a SPAN acknowledgement at 
the end of the paper. Some specific guidelines for use of a researcher's 
data and analysis programs are: 

1. Always have the expressed consent {written t» best) of the data 
provider before accessing files containing data or software. This means 
having a detailed understanding between the user and the provider of the 
bounds or limits of which <i.'ta can be accessed. An O.K. to look at one 
orbit's worth of data does sot give full rights to look at any other orbit. 
Also, the "provider" should be the PI of the Instrument and not just someone 
else who has access to the data. However, the Pi can delegate this control 
to others. 


2. The provider must be notified of the uses of the data or software 
borrowed. The provider should be notified at the earliest possible time 
should new results come from the use of the data or software and mutually 
agreed upon terms should be obtained which clearly lay out the roles of the 
provider and user in further research efforts. This will result both in the 
appropriate acknowledgement of the provider (either in the acknowledgements 
or as a co-author of the publication) and in the correct use of the data. 

3. In cases where data or software are used in a publication, submit- 
ting a copy of the paper to the provider prior to submission is highly desire- 
able. The provider will then have an opportunity to see that the data or 
software are not misused. 

4. No data or software obtained from another user should ever be 
distributed to anyone else without the express consent of the provider. This 
includes the user showing fellow col laborators plots or other results unless 
the provider is aware of the other researcher's involvement and agreement by 
the other researcher to observe the proprietary rights to the data. 


A user should not assume that adding the provider's name to the list of co- 
authors of a paper or abstract will be a substitute for obtaining the proper 
set of agreements with the provider. A person may be just as upset by being 
an unwilling co-author as by being left off the author list. 
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B. Network Security 


SPAN membership entails certain responsibilities. One of these responsibili- 
ties Is to take reasonable local computer system security precautions. If a 
system Is not hooked to anything but several local terminals, then the need 
for security precautions Is low. But when a machine Is attached to a wide 
area network {such as SPAN) and/or has one or more dialup terminal ports, 
then It becomes necessary for the system management to see that resonable 
security precautions are taken. This is to insure that: 

1. the system will not easily allow unauthorized users access to 
files and accounts on the local system, and 

2. that the local system will not allow unauthorized users to access 
the network. 

It is not necessary for the system management to "lock up" the system and 
make It difficult for users to access, but it is necessary that security be 
taken seriously by all users (especially system managers). 

The following is a list of security guidelines that should be considered to 
be a minimal set of security precautions. Most are specific to VAX/VMS 
systems, but many also have relevance to RSX systems. Nearly all are simple, 
common sense measures that will go far in ensuring local and network security. 


Local User Accounts 


Accounts should be assigned to users on a one account/ one user basis. This 
is to emphasize user responsibility and accountability. If a group of people 
need to work on each other's files, they should all be placed in the same UIC 
user group so group UIC protection can be utilized. Where it is necessary to 
have mutilple user accounts, care should be taken as to who is allowed to 
know the password and use it. Passwords for multiuser accounts become public 
knowledge quite quickly if precautions are not taken. A single individual 
should be assigned the task of being responsible for an account's password. 
Any user needing to know the password to such an account should get the pass- 
word from that person and not another user. This method will ensure that at 
least one person will know all the users who have legitimate access to a 
multiuser account. There should be at least a semiannual review of all user 
accounts. Accounts that are assigned to users that have left or are no 
longer being used should be removed from the system. 


Password Protection 


Probably the single most important measure a system manager can impelement is 
to be sure that there are no trival passwords in use on his system. Pass- 
words should NOT be the user's first name, the same name as used for the 
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account, or a simple carriage return. Passwords should be at least eight 
characters In length and should use special characters, l.e., the dollar sign 
and underscore (VAX/VMS). Users should not make their passwords known to 
other users. If a user needs to access something from a different account, 
the files needed should be set to world or group read access. Users should 
change their passwords at least once every several weeks. If the system 
manager finds that a user refuses to keep a password on his account, he 
should lock a nontrivial password on the account. Newly created accoui'^ 
should not be given trivial passwords such as a user's first name. Newly 
created accounts should be given an adequate password and the users should be 
told to change the password to something new on their first use of the 
account. 


Authorization Flags 


VAX/ VMS managers have a number of account flags that can be set In the system 
authorization file (SYSUAF.DAT) . These flags are set by the use of the Author- 
ize Utility. First, flags which should be on all newly created accounts 
should be set on the default account record in SYSUAF.DAT. One flag that 
should be default on all user accounts Is the DISDIALUP flag (for both pri- 
mary and secondary days). All accounts should be created with this flag and 
It should be removed only if the user has a need for logging onto the system 
over dialup ports. (This method will not work on systems which use Gandalf 
PBX's to attach terminals to tennlnal ports.) System accounts on a VAX/VMS 
system should have the DISDIALUP and DISNETWORK flags set to force privileged 
u*.: of the system to be done locally. System accounts which are not used on 
a regular basis should be DISUSERed to make interactive log-in Impossible 
(i.e., SYSTEST). 


DECnet Default Accounts 


The DECnet default account in use on nearly all SPAN nodes Is a security 
problem. Default accounts on VAX/VMS systems should have the following 
authorization flags set: DISDIALUP, DISNETWORK (both primary and secondary 
days), DISUSER, LOCKPWD, CAPTIVE, and DISCTLY. The default account should 
never be used for interactive use. It has been found that privileged DECnet 
default accounts are of little use and are a large security problem. Most 
nodes will find that removing this account from the system will not Incon- 
venience the system or network manager. Default account protection on RSX 
systems is more of a problem due to the lack of the sophisticated controls 
available In VAX/VMS. The best way to keep the default account from being 
compromised is to make the password something other than "net" or "decnet" 
and allow the password to be known only to other system managers on the net- 
work for use in their DECnet data bases. AGAIN, DFCNET DEFAULT ACCOUNTS 
SHOULD NEVER SEE INTERACTIVE USE. 
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File Security 




DECnet makes remote file access and manipulation very easy and transparent. 
This can cause very large security problems. The system manager on a SPAN 
node should set his system-wide default protection to be NO world read, 
write, execute, and delete. It must be kept in mind that on a large network,, 
"world" Includes ALL users on ALL machines. If a user wants to allow the 
world read, execute access to all of his files, he can so specify In his 
log-in command file. Otherwise he can set individual files to world access so 
they can be copied or used from over the network. The system manager should 
Insure that all Important system files are set to allow nothing more than 
world read and execute. Files such as SYSUAF.DAT and NETUAF.DAT should be 
accessible only to the system manager. 


Other Measures 


Some other things that should be done to ensure local security include: 

1. Never leave any SYSUAF.LIS files in SYS$SYSTEM (VAX/VMS). 

2. Accounting should be turned on and the system manager should in- 
spect the output every month for unusual activity such as use of dialup ports 
and remote network log-ins during nonworking hours. System managers should 
inspect their system console printout frequently. 

3. System privileged accounts should be used by only the system man- 
ager. Privileges which allow a user total control of a machine should be 
withheld from users {SYSPRV, BYPASS, CMKRNL, DETACH, etc. for VAX/VMS 
systems) . 




V. SPECIAL NODES 


This section describes several special SPAN nodes. These nodes provide a 
unique service to the space science community. It Is anticipated that as the 
network grows the Importance of these NASA facilities to the science com- 
munity will Increase tremendously. 


The National Space Science Data Center (NSSDC) Node 


A. Introduction 

NSSDC is NASA's primary facility for the long-term archiving and dissemina- 
tion of spaceflight data. NSSDC offers to other SPAN nodes a number of on- 
line services to facilitate access to data and to information about online 
and offline data held at NSSDC and elsewhere. A number of these services are 
in the early development phase. Specifically, NSSDC offers online: 

1. accessibility of selected sensor data; 

2. accessibility of directory/ catalog information on the location, 
access procedures, and other characteristics of data held online and offline; 

3. requesting of data held offline at NSSDC; 

4. finding of persons' SPAN node address, mailing address, and tele- 
phone number; and 

5. information about the hardware/ software configuration and other 
characteristics of various SPAN nodes. 


A, brief description of the current services is kept in the NSSDC DECnet de 
fault directory, and can be read using the following command: 


$type NSSDC: SERVICES 


Online access to these menu-driven services, including documentation, may be 
obtained by logging-on to the NSSDC node using account NSSDC (password not 
required) using the following commands: 

set host NSSDC username: NSSDC 

Several of these services have individual accounts whos names and passwords 
can be obtained upon request from NSSDC; mail such requests to NSSDC: :NSSDC 
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B. Online Data Accessibility 


The first NSSDC data set to be brought to an online accessibility status is 
the hourly resolution Interplanetary magnetic field and plasma compilation. 
This data set comes from the 1963-1982 "omnitape" which has been used in the 
generation of the Interplanetary Medium Data Books and Supplements at NSSDC. 
The portion of this data set beginning January 1, 1976, is in file: 

NSSDC : : S YS$USR3 : [OMNI .DATA]0MNI .DAT 

This file will be extended into 1984 during 1985, The format for each record 
is the same as the "omnitape," and is given In file: 

NSSDC: :SYS$USR3:[0MNI.D0CUMENTS]0MNI. FORMAT. LIS 

A subroutine to read the records, starting at any user-specified record and 
then proceeding sequentially, is in file: 

NSSDC: :SYS$USR3: [OMNI ,PROGRAMS]RDOMNI .FOR 

Additional routines for listing parameters from the data file are in the 
library: 

NSSDC : : SYS5USR3 : [OMN I . PROGRAMS] 

The menu-driven access to this data and information is the response to 
selecting option 5 from the menu presented upon signing on to the NSSDC 
account on the NSSDC node. 

The first CDAW data base to be brought online on the SPAN network will be 
CDAW-8, which will focus on intervals of I SEE-3 deep-magnetotail passage. 
Availability is expected in mid-1985. This will be accessible by selecting 
option 2 from the NSSDC account on the NSSDC node. 

Additional data files will be brought to an online status as resources and 
demand warrant. NSSDC anticipates working closely with DSIMG in prioritizing 
data sets for such promotions. 


C. NSSDC Online Data Catalog System (NODCS) 

The NODCS consists of a high level directory (Central Online Data Directory - 
CODD) in which is held information about data sets in their entireties, and 
more detailed catalogs about data set granules (individual files, time in- 
crements, Images, etc.). The system is expected to span the full spectrum of 
space and Earth sciences, although most work to date has concentrated on the 
directory for solar-terrestrial data. 

A prototype version of the directory is available on the NSSDC VAX; the 
system uses the Oracle DBMS (Data Base Management System) (see Smith et al . 
[8]). The evolving menu-based user interface can be invoked by selecting 
option 3 from the menu displayed under the NSSDC account on the NSSDC node. 

As of December 1984, no discipline query capability is available, although 
such is planned for 1985. There is a scientific steering committee guiding 
NSSDC in the NODCS definition and development activities. However, feedback 
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from any member of the SPAN community would be carefully considered and high- 
ly appreciated. 

As an interim approach to communicating to the SPAN community information on 
the NSSDC offline data archive, the file 

NSSDC : : SYSSUSR3 : [NSSDC .CAT]AIM. LIS 

was created as a series of 80 character records. Each record identifies one 
NSSDC data set, and contains spacecraft name. Principal Investigator last 
name, 33-char, data set name, time span, form {e.g., mag tapes microfiche, 
etc.), and quantity of the data set. The VMS utility SEARCH may be used to 
select and list out records. For example: 

SEARCH NSSDC: :SYS$USR3:[NSSDC.CAT]AIM. LIS ISEE-3 

would result in a listing of all NSSDC held data sets from ISEE-3. Only data 
sets obtained from solar-terrestrial and heliospheric missions launched since 
1970 are included in this file at present. This Information is also availa- 
ble as option 4 from the menu presented on the NSSDC account on the NSSDC 
node. 

Online Ordering of NSSDC Held Offline Data Sets The account NSSDC on the 
NSSDC node can be used for Incoming mail not Intended for a person with his 
own account. Persons wishing to request data from NSSDC may use the VMS MAIL 
utility and SEND a message to NSSDC: :NSSDC. This mailbox will be scanned 
daily. Requests should be specific as possible, and should include a return 
U.S. mall address. Requests may also be submitted by selecting menu option 6 
under the NSSDC account and inserting information requested using a VMS 
editor. On exiting the editor the request will be automatically mailed to 
the correct account. 


D. SPAN Node Address Query System 

This service, available as menu option 7 under the NSSDC account on the NSSDC 
node, was established to enable SPAN users to determine the SPAN address, 
mailing address, and telephone address of other persons on the SPAN network. 
As the information available depends on the active support of the SPAN com- 
munity, a function has been added to allow users to submit information to be 
included in the data base after review by NSSDC personnel. It also permits 
review or submission of data to the SPAN node hardware/ software inventory 
described below. 


E. SPAN Node Hardware/ Software Inventory 

NSSDC has recently performed a survey to ascertain what equipment and soft- 
ware packages are in use at various SPAN nodes. The results of this survey 
are available in file: 

NSSDC: :SYS$USR3: [NSSDC] SURVEY. MEM 

It is intended that this file will be kept as current as information inflow 
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to NSSDC permits. Please use option 7 under the NSSDC account on the NSSDC 
node to submit information for this table. 


The Data System Technology Program (DSTP) Node 


The NASA Data System Technology Program {DSTP, formally called the NASA's 
End-to-End Data System or NEEDS) will be developing concepts and demon- 
strating technology over the next few years that will significantly reduce 
the time it takes for large amounts of acquired spacecraft data to be avail- 
able to the experimenter (NEEDS System Team [9]). The DSTP development is 
supported by the Office of Aeronautics and Space Technology (Code R) at NASA 
Headquarters. The DSTP system is being constructed at MSFC and is currently 
the central node of the SPAN system (node name has remained NEEDS). The DSTP 
is made up of two closely linked systems: a Data Base Management System 

(DBMS) and a Mass Memory Assembly (MMA), both of which are undergoing soft- 
ware and hardware integration. 

The DSTP/DBMS consists of several large mini-computers (three VAX 11/780' s, a 
POP 11/34, and a SEL) linked together by a high speed fiber optics bus with 
powerful data base management software to handle large quantities of data 
(see Thomas [1] for a system overview). The role of the DSTP/MMA is to store 
large multi-mission science and engineering data bases in a large permanent 
archive using optical disk media. The MMA will have the storage capacity of 
1 3 

10 bits on 125 optical disks. The MMA is desigined to archive data packet 
input at rates up to 50 megabits/ second. Plans are underway that will allow 
the archiving of Spacelab data with this system in near-real time in the 1986 
timeframe. 

The NEEDS node on SPAN, which is part of the DSTP, uses the Packet Management 
Software (PMS) developed at GSFC and ORACLE (a commercial relational data 
base management language) for user access to the MMA. 

It is anticipated that the DSTP NEEDS node will be released for general use 
by SPAN users by the end of 1985. 


Mission Integration and planning System (MIPS) Node 


The MIPS node is located at MSFC. MIPS is responsible for nearly all the 
timelining of shuttle-attached payloads such as Spacelab. Investigator in- 
puts into the MIPS include: experiment functional objectives, physical size 

and pointing information, and other - similar payload information required for 
mission implementation. It is expected that the addition of MIPS on SPAN 
will enhance pre-mission planning, provide shorter turnaround, improve commun- 
ication between users and planners, save manpower in the long run, and start 
the automation of the Spacelab mission planning process at the investigation 
level . 

MIPS also provides information by means of the mission timeline regarding 
when other experiments are operating and in what mode. This information is 




essential to know when one experiment affects the environment that another 
experiment Is measuring. Complete and up-to-date timeline Information will 
be essential for many of the science-dedicated missions, such as Space Plasma 
Laboratory. 

Initial use of HIPS allows normal POCC Interface files to be accessible to 
users. Users have been routinely supplying mission planning Information 
through SPAN to MIPS on request. Outside access to MIPS through SPAN will be 
restricted during POCC simulations or during a mission. Arrangements are 
currently being made to accommodate specific user requests. When it has been 
determined that remote access does not affect MIPS operation, remote users 
will be allowed access to MIPS during a mission. As MIPS becomes more sophis 
tlcated in Its mission planning capabilities. It will allow remote users to 
query the POCC data base and execute orblter orbit and attitude, and TDRSS 
tracking programs. Therefore, the remote access and use of MIPS by Spacelab 
Investigators is designed in an evolutionary approach increasing the inves- 
tigators' capabilities at each step. It is necessary to do this since the 
MIPS system was not originally designed to be Interrogated extensively by 
Spacelab/ SPAN users. 
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APPENDIX A - DSUWG MEMBERSHIP 






The chairman for the DSUWG is Dan Baker (LANL). The SPAN project scientist 
and manager is James Green (MSEC) and David Peters (MSFC/ INTERGRAPH) is the 
network manager. The following Is a list of the current DSUWG members in 
each subgroup. 


POLICY SUBGROUP 


Chai rman 


Dr. Ron Zwickl 
Members 

LANL 

505-667-3897 

Dr. 

Vincent Abreu 

U of Michigan 

313-763-6217 

Prof. Pat Reiff 

RICE UNIV 

713-527-4944 

Dr. 

Richard McEntire 

APL/JHU 

301-953-7100 

Dr. 

Ray Walker 

UCLA 

213-825-7685 

Dr. 

Eugene Greenstadt 

TRW 

213-536-2016 

Dr. 

Bob Theis 

GSFC 

301-344-7576 

Dr. 

Dave K1 umpar 

UTD 

214-690-2835 

Or. 

Stan Shawhan 

NASA HQ 

301-453-1676 

Dr. 

Mike Wiskerchen 

Stanford 

415-497-2848 

Dr. 

Bob McPherron 

UCLA 

213-825-1882 

Dr. 

Dan Baker 

LANL 

505-667-3101 

Mr. 

David Peters 

MSFC/ INTERGRAPH 

205-453-4625 


SOFTWARE 

AND GRAPHICS 

STANDARDS SUBGROUP 

Chai rman 

Dr. Dennis Gallagher 

NASA/ MSFC 

205-453-0818 

Co-Chairman 

Dr. Bill Peterson 

Lockheed 

415-858-4069 

Members 

Dr. Joe Doupnik 

USU 

801-750-2982 

Dr. Don Sawyer 

NSSDC 

301-344-8145 

Dr. Bill Taylor 

TRW 

213-536-2015 

Dr. Doug Menietti 

SwRI 

512-684-5111 

Ms. Lora L. Suther 

APL/JHU 

301-953-7100 

Dr. Howard Singer 

AFGL 

617-861-5757 

Dr. Thomas Moore 

NASA/ MSFC 

205-453-0028 

Dr. Roy Torbert 

UCSD 

714-452-3315 

Dr. Barry Mauk 

APL/JHU 

301-953-7100 

Dr. Carl Mcllwain 

UCSD 

714-452-3314 

Mr. Ron Janetzke 

SwRI 

512-684-5111 

Dr. Joe Bredekamp 

GSFC 

301-344-8451 

Dr. Robin Coley 

UTD 

214-690-2853 
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NETWORKING AND HARDWARE SUBGROUP 




Chai rman 

Or. Jim Green 

NASA/MSFC 

205-453-0028 

Co-Chairman 

Dr. Rob Gold 

APL/JHU 

301-953-7100 

Members 

Dr. Neal Cline 

UCLA 

213-825-3506 

Or. Jim Willet 

JPL 

213-354-5396 

Dr. Hunter Waite 

NASA/MSFC 

205-453-3037 

Dr. Douglas Potter 

U OF WASHINGTON 

206-543-9055 

Mr. Gordon Lentz 

U OF CHICAGO 

312-962-7836 

Mr. John Piotrowski 

JPL 

818-354-5491 

Dr. Calvin Teague 

Stanford 

415-497-3596 

Mr. Dick des Jardins 

CTA 

303-740-7026 

Dr. Fred Wul ff 

NASA HQ 

301-755-2430 

Mr, Bob Stevens 

NASA HQ 

301-755-2430 

Mr. Dennis Roth 

NSSDC 

301-344-6818 



DATA BASE STANDARDS 

SUBGROUP 

Chairman 

Dr. Joe King 

NSSDC 

301-344-7355 

Members 

Ms. Pat Asti 11 

NSSDC 

301-344-6818 

Dr. Bob Clauer 

Stanford 

415-497-4691 

Dr. Randy Davis 

U OF COLO 

303-492-6867 

Dr. Richard Munro 

HAO 

303-494-5151 

Dr. Jim Slavin 

JPL 

213-345-2881 

Mr. Bob Power 

UTD 

214-690-2852 

Dr. Paul Smith 

GSFC 

301-344-5876 


APPENDIX B - SPAN PRIMER 


Introduction 

The purpose of the SPAN is to support communications between users on network' 
nodes. This includes data access and exchange, electronic ma'.l communica- 
tion, and sharing of resources among members of the space science community 
( see Green et al . [2]) . 

Communication between nodes on the SPAN is accomplished by means of DECNET 
software. DECNET software creates and maintains logical links between net- 
work nodes with different or similar operating systems. The operating 
systems currently In use on SPAN are VAX/VMS, RSX, and IAS. DECNET provides 
network control, automatic routing of messages, and a user interface to the 
network. The DECNET user Interface provides commonly needed functions for 
both terminal users and programs. The purpose of this appendix is to provide 
a guide on the specific implementation of DECNET on SPAN and Is not Intended 
to replace the extensive manuals on DECNET already produced by DEC. 

DECNET supports the following functions for network users: 

1. TASK-TO-TASK COMMUNICATIONS: User tasks can exchange data over a 

network logical link. The communicating tasks can be on the same or differ- 
ent nodes. Task-to-task communication can be used to initiate and control 
tasks on remote nodes. 

2. REMOTE FILE ACCESS: Users can access files on remote nodes at a 

terminal or within a program. At a terminal, users can transfer files 
between nodes, display files and directories from remote nodes, and submit 
files containing commands for execution at a remote node. Inside a program, 
users can read and write files residing at a remote node. 

3. TERMINAL COMMUNICATIONS: RSX and IAS users can send messages to 

terminals on remote RSX or IAS nodes. This capability is available on VMS 
nodes by using the PHONE utility. 

4. MAIL FACILITY: VMS users can send mail messages to accounts on 

remote VMS nodes. This capability is currently available for RSX and IAS 
nodes but is not supported by DEC. There are slight variations for RSX and 
IAS network mail compared to VMS mail . 

5. REMOTE HOST: VMS, RSX, and IAS users can log-on to a remote host 

as if their terminal were local. 


Network Implementations 


The SPAN includes implementations for RSX, IAS and VAX/VMS operating systems. 
DECNET software exists at all the SPAN nodes and it allows for the communica- 
tion of data and messages between any of the nodes. Each of the network 
nodes has a version of DECNET that is compatible with the operating system of 
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that node. These versions of DECNET have been presently developed to diffe- 
rent extents causing some nodes to have more or less capabilities than other 
nodes. The version or "phase" of the DECNET, as it Is called, indicates the 
capability of of that node to perform certain levels of communication. Since 
RSX and IAS implementations are almost identical, they are described together. 

Users need not have any special privileges (VAX/VMS users will need NETM8X 
privileges on their account) to run network tasks or create programs which 
access the network. However users must supply valid access control informa- 
tion to be able to use resources. The term "access control" refers to the 
user name and password of an account (local or on a remote node). 

Online system documentation is a particularly important and valuable compo- 
nent of DEC systems. At the present, SPAN is comprised almost completely of 
DEC systems. An extensive set of system help files and libraries exist on 
all the SPAN DEC nodes. The HELP command invokes the HELP utility, to display 
information about a particular topic. The HELP utility retrieves help availa- 
ble in the system help files or in any help library that you specify. You 
can also specify a set of default help libraries for HELP to search in addi- 
tion to these libraries. 

Format: HELP [keyword [...]] 


On many systems new users can display a tutorial explanation of HELP by 
typing TUTORIAL in response to the "HELP Subtopic?" prompt and pressing the 
RETURN key. 


UTILITIES FOR DECNET-VAX 


VAX terminal users have several utility programs for network communications 
available from the VMS operating system. Documentation for most of these 
ut-ilities can be found in the Utility Reference Manual of the VAX/ VMS manual 
set and each utility has extensive online help available. The following 
descriptions are a brief introduction to these utilities: 

MAIL: The VAX/VMS mail utility allows you to send a message to any 

account or to a series of accounts on the network. To send a message, you 
must know the account name of the person you wish to contact and his node 
name or node number. (This will be covered more extensively in the section 
Utilities for all DEC SPAN nodes.) 

FINGER: The DECUS VAX/VMS Finger utility has been installed on a 

number of SPAN VAX/VMS systems. (Ask your system manager as to its availa- 
blity.) Finger allows a user to see who is doing what both on his machine 
and on other machines on the network that support Finger. Finger also allows 
a user to find information on the location and accounts used by other users, 
both locally and on the network. If your VAX supports VMS Finger, further 
information can be found by typing HELP FINGER. 



PHONE: The VAX/VMS PHONE utility allows you to have an interactive 

conversation with any other current user on the network. This utility can 
only be used on video terminals which support direct cursor positioning. The 
local system manager should know if your terminal can support this utility. 

To initiate a phone call, enter the OCL command PHONE. This should clear the 
screen and set up the phone screen format. The following commands can be 
executed : 

DIAL nodename: : username 

Placing a call to another user. You must wait for a response from that user 
to continue. DIAL Is the default command if just nodename: : username is 
entered . 

ANSWER Answers the phone when you receive a call. 

HANGUP Ends the conversation (you could also enter a CTRL/Z). 

REJECT Rejects the phone call that has been received. 

DIR nodename:: Displays a list of all current users. This command is 
extremely useful to list current users on other nodes of the network. 

FACSIMILE filename Will send the specified file to your listener as 
part of your conversation. 


To execute any of these commands during a conversation, the switch hook 
character must be enter first. By default, that character is the percent key. 

DCL commands will act transparently over the network. For example, to copy a 
file from a remote node: 

$copy 

From: "username password"node: : di sk : Cd i rectory] f i 1 e .1 is 
To: newfile.lis 


This will copy "file. 11s" in "directory" on "node" to the account the command 
was issued in and name it "newfile.lis". The access information (user name 
and password of the remote account/ is enclosed in quotes. Note that you can 
also copy that same file to any other node and account you desire. As 
another example, to get a directory listing from a remote node use the follow' 
ing command: 

$dir node:: [directory] (if on the default disk) 


UTILITIES FOR DECNET-11M/DECNET-IAS 


There are certain DECNET functions that can only be done on nodes that have 
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the same type of operating systems such as the SSL, TRW, SPRL, and UTD nodes 
both with an RSX-I1M operating system. The capabilities offered to the RSX 
DECNET user can be broken down into two major categories: those functions 

for terminal users and those functions for FORTRAN programmers. 

OECNET-UM terminal users have several utility programs available to them 
which allows logging onto other machines in the network, file transfers, 
message communication, and network status Information. 

REMOTE-LOGON: The REMOTE-LOGON procedure allows a user at a node to 

log-on to another node in the network. This capability Is also called 
virtual terminal. RVT is the host to terminal program which allows the user 
to log-on to adjacent nodes in the network from a DECNET-11M node. This 
program Is initiated by typing "RVT" and answering the HOST question with the 
network node name. The "SET HOST" command on the SPAN-VAX also allows you to 
log-on to adjacent nodes. Both programs can be used as In the following 
example. To log-on to the UTD node the following procedure is needed: 

Use RVT to log-on to say the NEEDS VAX (>RVT NEEDS). 

On the VAX type "SET HOST" (note; UTD can be reach directly with a >RVT UTD 
response) . 

Enter the node name; "UTD" 

At this point you will see the MCR prompt > 

Log-or to that node. 

When finished type "BYE" (to leave MCR) 

To log-off the Vax type "LOGOUT" 


The use of RVT should be limited since it requires many resources on a POP. 


NETWORK FILE TRANSFER: NFT is the Network File Transfer program and 

is part of the DECNET software. It is Invoked by typing NFT <CR> to file = 
from file or by typing NFT to file = from file. Embedded in the file names 
must be the node name, access information, and directory if it is different 
than the default conventions. The following structure for the file names 
must be used when talking to the NEEDS node with NFT. 

NODE/ username/ password: : Dev : [dir .sub-dl rjfi'le.type 
where, Dev is either DRAO: or DRA1: (or other drive designations). 
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The following NFT switches are very useful: 

/LI Directory listing switch. 

/AP Appends/adds files to end of existing file. 

/DE Deletes one or more files. 

/EX Executes command file stored on remote/ local node. 

/SB Submits command fih<» for execution { remote/ local ) . 

/ SP Spools files to line printer (works only with "like" nodes) 

A particular use for NFT Is for the display of graphics files on the network 
(Gallagher et al . [10]). It Is important to note, however, that some device 
dependent graphics files are not all dlsplayable such as those generated by 
IGL software. The graphics files generated by the MSSL graphics package are 
displayable when residing at other nodes by using the following input: 

NFT> TI :=SP AN/NET/NET : :[NETNET.R1MS]D1364 .COL 

Graphics files generated by IGL can be displayed by running either REPLAY or 
NETREP programs (see the net-library documentation). 


TERMINAL COMMUNICATIONS: TLK Is the Terminal Communications Utility 

which allows users to exchange messages through their terminals. TLK 
resembles somewhat the RSX broadcast command but with more capabilities. TLK 
currently works only between RSX-11 nodes and within a RSX-11 node. There 
are two basic modes of operation for TLK: single message mode and the 

dialogue mode. 

The single message mode conveys short messages to any terminal in the same 
node or remote node. The syntex for this operation is: 

>TLK TARGETNODE: :TTn : — Message— 

The dialogue mode allows you to have a conversation with another network 
terminal user. 

To initiate the dialogue mode type: 

>TLK TARGETNODE: :TTn<cr> 

What will be printed out will be: 

<TLK> - START OF DIALOGUE TLK> 

When you receive the TLK> prompt, you can enter a new message line. 


NETWORK CONTROL PROGRAM: NCP is the Network Control Program and is 

designed to primarily help the network manager. However, there are a number 
of NCP commands which can be of general use to the unprlviledged user. With 
these commands the user can quickly determine node names and whether nodes 
are reachable or not. Help can be obtained by entering NCP>HELP and continu- 
ing from there. For a complete listing of all the NCP commands that are 
available to unpriviledged users refer to the NCP appendix of the DECNET-11M 
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manual. The following Is a partial listing of NCP commands that should be 
the most beneficial to users: 

NCP> SHOW KNOWN NODES NCP> SHOW ACTIVE NODES 


UTILITIES FOR ALL DEC SPAN NODES 


One of the main objectives of the SPAN system project Is to accommodate 
coordinated data analysis without leaving one's Institution. Therefore there 
Is a strong need to develop the ability to have graphic images of data from 
any node to be displayed by any other node. The current Inability to display 
data on an arbitrary graphics device at any node has been quickly recognized. 
As general network utilities are developed to support the display -of device 
dependent and independent graphic images, the handbook SPAN GRAPHICS DISPLAY 
UTILITIES HANDBOOK by Gallagher et al . [10] will serve to document their use 
and limitations. The graphics handbook is a practical guide to those common 
network facilities which will be used to support network correlative studies 
from the one-to-one to the workshop levels. For each graphics software 
utility the handbook contains information necessary to obtain, use, and 
implement the utility. 


Mail 

As briefly discussed earlier all SPAN DEC nodes have a network mail utility. 
Before sending a mail message, the node name and user name must be known. 

The next section will discuss the SPAN wide user name facility that aids in 
finding SPAN users. The node names are listed in Appendix D. 

To send a message to the network manager, you would enter the following 
commands (user entered information is capitalized): 

$ MAIL 

mai 1> SEND 

to: NEEDS:: PETERS 

subj : MAIL UTILITY TEST 

Enter your message below. Press Ctrl /z when complete ctrl/c to quit: 

DAVE, OUR NETWORK CONNECTION IS NOW AVAILABLE AT ALL TIMES. WE ARE 
LOOKING FORWARD TO WORKING FULL TIME ON THE SPAN. WE ARE ALSO SEARCHING FOR 
A SCIENTIFIC ANALYSIS PACKAGE FOR OUR VAX. DO YOU KNOW OF ANY THAT MAY BE OF 
USE TO US? THANKS FOR ALL YOUR HELP. 

JOHN CTRL/Z 


mail>EXIT 

In order to send mail to more than one user list the desired network users on 
the same line as the TO: command separating each with a comma. Another way 

to accomplish this is to use a file of names. For example v 1r the file 
SEPAC.DIS, all SEPAC investigators on SPAN are listed: 
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NEEDS: : ROBERTS 
NEEDS: :REASONER 
NEEDS: :GRECN 
SWRI : : J IM 
TRW:: TAYLOR 
STAR: :WIL l_I AMSON 


The network mail utility will send duplicate messages to all those named in 
the above file by putting the file name on the TO: command line {TO: @SEPAC) . 

A second option for the SEND command is to include a file name which contains 
the text to be sent. You will still be prompted for the TO: and SUBJ: 

information. The following statements give a brief description of other 
functions of the mail utility: READ n Will list, on the terminal, the mall 1 
message corresponding to number n. If n is not entered, any new mail mes- 
sages will be listed. 

FILE Saves a copy of the current message to a designated file. 

FORWARD Sends a copy of the current message to other users. 

REPLY Allows you to send a message to the sender of the current 
message. 

DIR Lists all messages and their numbers that you have received. 
These numbers can then be used with the READ command. 


Network User Lists 


A list of users for any of the SPAN nodes has been implemented as a distrib- 
uted system for which the node managers are responsible for. The following 
is a partial example of a userlist on node NEEDS. The complete list can be 
displayed or searched on over the network using standard operating system 
commands (for example; $TYPE NEEDS: :USERLIST) . 


Owner 

User Name 

UIC 

Account Default Directory 

RICK CHAPPELL 

CHAPPELL 

[165,001] ES51 

0R0: [CHAPPELL] 

JOHN CLARKE 

CLARKE 

[214,001] ES62 

DRO: [CLARKE] 

PAUL CRAVEN 

CRAVEN 

[206,001] ES53 

0R0: [CRAVEN] 

DBMS 

DBMS 

[100,001] DBMS 

DRO: [DBMS] 

DOUG THOMAS 

DOUG 

[105,001] EB32 

DRO: [THOMAS] 

BARBARA GILES 

GILES 

[153,001] ES53 

DR0:[GILES] 

JIM GREEN 

GREEN 

[161,001] ES53 

DRO -.[GREEN] 

RICK HELMICK 

HELMICK 

[143,001] AN31 

DRO: [HELMICK] 

JOE GALEY 

JA51 

[347,001] JA51 

DR0:[JA51] 

MORAYMA LUIS 

LUIS 

[145,001] EL12 

DRO: [LUIS] 

TOM MOORE 

MOORE 

[205,001] ES53 

DRO -.[MOORE] 
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Owner 


User Name 

UIC 

Account Default Directory 

PMS 


PMSAPLIB 

[075,001] DBMS 

DRO: [PMSAPLIB] 

LINDA 

PORTER 

PORTER 

[221,001] ES01 

DRO: [PORTER] 

DAVID 

REASONER 

REASONER 

[162,001] ES53 

DRO: [REASONER] 

HUNTER 

1 WAITE 

WAITE 

[163,001] ES53 

DR0:[WAITE] 


FACILITY LISTING OF NETWORK NODES 


Much like the user list, a network-wide facility listing is available for 
each node in their network default account. The following example is for the 
APL node. Other node facility information can be obtained by typing 
NODE: : NODEINFO. 

APL 

MAIN ADDRESS FOR MAIL AND PACKAGES 

Lora Suther 2-150 
JHU APL 

Johns Hopkins Rd, Laurel, MD 20707 


OFFICE PHONE (301) 953-5000 x8412 


PHYSICAL LOCATION OF THE APL VAX 

Building 2-46 
JHU APL 

Johns Hopkins Rd. Laurel, MD 20707 


PHONE NUMBERS 

Terminal room (301) 953-5000 x8415 
Computer room (301) 953-5701 (direct dial-in) 

DESCRIPTION OF THE APL VAX 

VAX 11/780 currently running VAX/VMS V3.5 with 
6 MB physical memory 
1 RP07 disk drive 
1 TU78 6250/1600 tape drive 
4 Kennedy 1600/800 tape drives 

1 DMR-11 

2 DZ-lls 

1 RAMTEK 9400 color graphics system 
1 GOULD printer/ pi otter 
1 dial-up line 
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Software Includes: 

VAX-1 1 FORTRAN 

DECnet 

NCAR 

Assorted CAICOMP compatible libraries. 
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APPENDIX C - DATA BASE MANAGEMENT 


To be completed by June 1985 


APPENDIX D - KNOWN NODE SUMMARY AS OF FEBRUARY 21, 1985 


INSTITUTION 

NODE 

(Address) 

Machine 

Applied physics Laboratory 

APL 

1.35 

VAX 

11/780 

Goddard Space Flight Center 

National Space Science Data Center 

NSSDC 

1.43 

VAX 

11/780 

Code 960 

PACF 

1.40 

VAX 

11/780 

Code 740 

VX740 

1.41 

VAX 

11/780 

Code 690 

LEPVAX 

1.44 

VAX 

11/780 

Code 690 

SIRIS 

1.42 

VAX 

11/730 

Jet Propulsion Laboratory 

Planetary Pilot Data System 

PPDS 

5.1 

VAX 

11/780 

Planetary Image Processing Facility 

JPLIF 

5.6 

VAX 

11/725 

PPDS Management PR0350 

JPLPR0 

5.20 

PRO 

350 

Lockheed Palo Alto Research Laboratory 

L0CKHD 

1.52 

VAX 

11/750 

Los Alamos National Laboratory 

XNET Central Routing Node 

XNET 1 

1.4 

VAX 

11/780 

Earth Space Science Data Processing 2 

ESSDP2 

1.5 

VAX 

11/780 

Earth Space Science Data Processing 1 

ESSDP1 

1.15 

VAX 

11/780 

Marshall Space Flight Center 

Data System Technology Program 

NEEDS 

1.36 

VAX 

11/780 

Space Science Laboratory 

SSL 

1.37 

PDP 

1.1/34 

NEEDS DECnet Router Server 

ROUTER 

1.38 

Comm. Server 

Marshall Interactive Planning Sys.l 

MIPS1 

1.230 

VAX 

11/780 

Marshall Interactive Planning Sys.4 

MIPS4 

1.231 

VAX 

11/780 

Operations Testing System (SUNSTAR) 

0MIS1 

1.235 

VAX 

11/750 

Southwest Research Institute 

SWRI 

1.62 

VAX 

11/750 

Stanford University 
Stanford Telecommunications and Radio 

Science Laboratory 

STAR 

1.45 

VAX 

11/780 

Second STAR System 

STAR1 

1.49 

VAX 

11/780 

Science Payload Operation Control Cntr. 

SPOCC 

1.46 

VAX 

11/750 

Spacelab Experiment VAX 

VCAP 

1.47 

VAX 

11/750 

Stanford Solar Studies Group 

CORONA 

1.48 

VAX 

11/750 

Stanford Spacelab Testbed PR0350 

PR01 

1.67 

PRO 

350 

Stanford Spacelab Testbed PR0350 

PR02 

1.68 

PRO 

350 

University of California Los Angeles 

VXBMS 

1.83 

VAX 

11/780 

University of California San Diego 

La Jolla Space Physics 01 

LJSP01 

1.50 

VAX 

11/780 

La Jolla Space Physics 02 

LJSP02 

1.51 

PDP 

11/70 

University of Iowa 

IOWA 

1.64 

VAX 

11/780 
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Un,Ws| ty Of Texas at DaUas 
Utah sta te University 


UT ° 1,61 POP 11/23+ 

USU 1,70 POP li/7o 
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APPENDIX E - LIST OF ACRONYMS 


AE - Atmospheric Explorer 

ATTCOM - AT and T Communications 

CDAW - Coordinated Data Analysis Workshop 

CDSF - Central Data Services Facility (branch of the NSSDC) 

CLASS VI- A class of extremely fast computers (Cray, Cyber) 

CODD - Central Online Data Directory 

DBMS - Data Base Management System 

DDCMP - DEC "level II" network protocol 

DDS - Digital Data Service 

DE - Dynamics Explorer 

DEC - Digital Equipment Corporation 

DECNET - DEC networking products generic family name 

DMA - Di rect Memory Access 

DMR-11 - DEC UNIBUS computer DMA networking hardware 
DMSF - Data Management Systems Facility 
DMV-11 - DEC Q-BUS computer DMA networking hardware 
DSTP - Data Systems Technology Program (at MSFC) 

DSUWG - Data System Users Working Group 

GSFC - Goddard Space Flight Center 

IMP - Interplanetary Monitering platform 

ISEE - International Sun-Earth Explorer 

LANL - Los Alamos National Laboratory 

MFENET - Magnetic Fusion Energy Network 

MIPS1 - Mission Integration and Planning System #1 (MSFC) 

MMA - Mass Memory Assembly (connected to the DSTP) 

MSFC - Marshall Space Flight Center 

NEEDS - NASA's End-to-End Data System 

NODCS - NSSDC Online Data Catalog System 

NSSDC - National Space Science Data Center (at GSFC) 

PACF - Planetary Atmospheres Computing Facility (at GSFC) 
PCDS - Pilot Climate Data System 

PI - Principal Investigator 

PLDS - Pilot Land Data System 

PMS - Packet Management System 

POCC - Payload Operations Control Center 

PPDS - Planetary Pilot Data System 

PSCN - Program Support Communications Network 

SCAN - Space- plasma Computer Analysis Network (former name 

for SPAN) 

SPAN - Space Physics Analysis Network 

SSL - Space Science Laboratory (at MSFC) 

STARLAB - Stanford Telecommunications and Radio Science 
Laboratory 

TDRSS - Tracking and Data Relay Satellite System 
UIC - User Identification Code 

X.25 - A "level II" communication protocol for packet 

switch networks 
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Figure 1. SPAN nodes as of November 1984. 



: igure 2. SPAN communication configuration as of November 1984. 
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